-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make all interpolated string handlers pass by ref #57536
Conversation
We currently pass all of our interpolated string handlers to their destination methods by ref, with the exception of those for Debug. I think it makes sense to centralize on the pattern of always passing by ref: it doesn’t negatively impact the user experience, these are typically larger structs and so by ref helps (though it doesn’t matter for Debug), making it a ref makes it even less attractive to try to call directly / makes it look even more special, and most importantly, it gives us the opportunity to more safely clean up at the end of the operation. This changes the Debug.Assert/Write{Line}If overloads we added in Preview 7 to pass the handler’s by ref. This also then updates the Debug.Write{Line}If methods to create the StringBuilder used via StringBuilderCache, just in case these are used in a scenario where true is frequently passed.
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsWe currently pass all of our interpolated string handlers to their destination methods by ref, with the exception of those for Debug. I think it makes sense to centralize on the pattern of always passing by ref: it doesn’t negatively impact the user experience, these are typically larger structs and so by ref helps (though it doesn’t matter for Debug), making it a ref makes it even less attractive to try to call directly / makes it look even more special, and most importantly, it gives us the opportunity to more safely clean up at the end of the operation. This changes the Debug.Assert/Write{Line}If overloads we added in Preview 7 to pass the handler’s by ref. This also then updates the Debug.Write{Line}If methods to create the StringBuilder used via StringBuilderCache, just in case these are used in a scenario where true is frequently passed. With the handler passed by ref, we can more correctly clean up. cc: @bartonjs, @GrabYourPitchforks
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change LGTM - do you have time to open a blocking issue for discussing this in API review tomorrow or do you need a confederate to help out?
I'd like to get this in before the snap tomorrow. If we can discuss it first thing at the API review, that should be ok. I also don't think we ever discussed the ref in this specific case or not. |
We currently pass all of our interpolated string handlers to their destination methods by ref, with the exception of those for Debug. I think it makes sense to centralize on the pattern of always passing by ref: it doesn’t negatively impact the user experience, these are typically larger structs and so by ref helps (though it doesn’t matter for Debug), making it a ref makes it even less attractive to try to call directly / makes it look even more special, and most importantly, it gives us the opportunity to more safely clean up at the end of the operation. This changes the Debug.Assert/Write{Line}If overloads we added in Preview 7 to pass the handler’s by ref.
This also then updates the Debug.Write{Line}If methods to create the StringBuilder used via StringBuilderCache, just in case these are used in a scenario where true is frequently passed. With the handler passed by ref, we can more correctly clean up.
cc: @bartonjs, @GrabYourPitchforks
Fixes #57526
Fixes #57538